1. Field of the Invention
The present invention relates to the field of integrated circuits and, more particularly, to co-simulating physical implementations of integrated circuits with software environments.
2. Description of the Related Art
Electronic circuit designs can be constructed, simulated, debugged, and translated into electronic hardware using a High Level Modeling System (HLMS). Typically, an HLMS is implemented as a software-based design tool which provides blocks that can be combined to build a circuit design. A block refers to a high level software construct which represents a particular circuit function, such as multiplexing, addition, multiplication, or the like. The blocks can be arranged within the HLMS to form a circuit and/or system. Communication among the blocks can be represented by wires, or signals, which graphically link the blocks. Once configured, the HLMS can run various simulations upon the design. The HLMS further can generate a hardware implementation from the block representation of the circuit design. For example, an HLMS can generate the bitstream necessary to program a field programmable gate array (FPGA) or can generate hardware description language (HDL) files necessary to specify the hardware design.
One example of an HLMS is System Generator™, available from Xilinx, Inc. of San Jose, Calif. System Generator™ is a system level modeling tool that facilitates FPGA hardware design. System Generator™ can function with other design tools to provide a modeling environment that is well suited to hardware design. The System Generator™ tool provides high level abstractions for hardware algorithms and resources using blocks. A block has ports which allow it to be connected to other blocks in a diagram. Two ports are connected together via a net, which allows information, or data, to travel between the ports. System generator blocks can be automatically compiled into an FPGA. In addition, access to underlying FPGA resources can be provided through low level block abstractions which facilitate the construction of highly efficient FPGA designs.
It is possible to incorporate circuit designs, which already have been implemented in hardware, back into the HLMS development environment. FIG. 1 is a schematic diagram illustrating a conventional co-simulation system 100. The co-simulation system 100 depicts the situation in which a hardware implementation has been incorporated into an HLMS environment. As shown, a host computer system 105 can execute an HLMS 110. Within the HLMS 110, a programmable logic device (PLD) 130, for example an FPGA, has been represented by a proxy referred to as a hardware co-simulation block 115. The hardware co-simulation block 115 functions in much the same way as other blocks within the HLMS 110 in that it can consume signals from other blocks of the device under test (DUT) 120 and generate signals that can be interpreted by other blocks of the DUT 120.
The hardware co-simulation block 115 communicates with a co-simulation engine 125, also executing within the host computer system 105. The co-simulation engine 125 typically is provided by the vendor of the PLD 130 which has been incorporated into the HLMS 110 via the hardware co-simulation block 115 proxy. While shown independently of the HLMS 110, the co-simulation engine 125 usually integrates with the HLMS 110 as a plug-in. In any case, the co-simulation engine 125 communicates with the hardware platform 135, i.e., a simulation board upon which PLD 130 is disposed. In general, the hardware co-simulation block 115 executes generic function calls to the co-simulation engine 125. These generic function calls can include, but are not limited to, opening and closing commands directed to the hardware platform 135, commands for managing data I/O with the hardware platform 135, and commands for controlling clock sources for the PLD 130.
When the HLMS 110 compiles a particular circuit design, in this case the DUT 120, for hardware co-simulation, an HDL wrapper 140 can be generated. The HDL wrapper 140 specifies a memory map interface as well as clock control logic. The memory map interface sets aside a portion of memory in the PLD 130 itself which can be used to store input and output values for the co-simulated circuit, or the DUT 120. Elements of the memory map correspond to I/O ports on the hardware co-simulation block 115. The hardware co-simulation block 115 reads and writes to specific ports on the DUT 120 by generating an address that can be decoded by the memory map. The address is computed using the index of a hardware co-simulation block port to generate an address offset.
The co-simulation engine 125 translates the generic function calls from the hardware co-simulation block 115 into instructions specific to the hardware platform 135, and thus the PLD 130. The instructions are sent from the co-simulation engine 125 to the hardware platform 135 via a communication channel 145. Typically, the communication channel 145 is the channel and/or interface provided by the hardware platform 135, for example an interface such as PCI, JTAG (IEEE Standard 1149.1), USB, Ethernet, or the like.
With respect to co-simulation, speed often is critical. As such, certain communication interfaces and protocols are better suited for co-simulation than others. In general, the performance of a communication interface and protocol, as it relates to co-simulation, can be measured in terms of latency and available bandwidth. While bandwidth can be an important factor in the performance of a communication interface, typically it is less significant than latency. Latency, as used herein, can refer to the total delay, inclusive of transaction setup time, associated with transmitting to, or receiving data from, the hardware platform 135.
During co-simulation, new transactions are initiated from the co-simulation engine 125 to the hardware platform 135 under several different circumstances. These circumstances can include, but are not limited to, the case where an input port value changes on the hardware co-simulation block 115, the case where a hardware co-simulation block 115 output port must be updated, or the case where the hardware clock must be run in order to keep the PLD 130 in lockstep with the HLMS 110 simulation. It is also necessary for the co-simulation engine 125 to communicate with the hardware platform 135 to initialize and close the PLD 130. In such circumstances, however, latency does not significantly contribute to the overall simulation performance.
The amount of data transmitted for each individual transaction can vary. For I/O port updates, the data size typically is small (e.g., 64 bits). The different transactions outlined above are performed frequently in the context of co-simulation. The number of transactions performed per simulation cycle is proportional to the number of I/O ports on the hardware co-simulation block 115. As used herein, a simulation cycle in the HLMS 110 corresponds to a tick of the clock of the synchronization mechanism which drives the various components of the so-simulation. One example of a synchronization mechanism is Simulink®, which is a platform for multi-domain simulation and model-based design for dynamic systems, available from The MathWorks, Inc. of Natick, Mass. The synchronization mechanism can advance time forward, update data, and then advance time again. The time period beginning with a time advance and ending with a next time advance can be referred to as a simulation cycle. In general, a simulation cycle corresponds to a number of clock cycles in the PLD 130. While the number of PLD 130 clock cycles that correspond to a simulation cycle can vary, the number does remain constant within a given co-simulation session.
Frequent small transactions exchanged between the host computer system 105 and the hardware platform 135, which are inherent to co-simulation, can adversely affect data throughput when the communication interface and/or protocol is associated with high latency. For instance, the HLMS 110 simulation time cannot advance forward until the output port of a co-simulation block is updated, as there may be downstream blocks in the diagram which depend on such data. Bandwidth effectively is wasted in repeated transactional overhead or setup. Lower throughput can significantly hinder HLMS simulation performance. Further, this manner of co-simulation communication does not scale well as the number of ports on the hardware co-simulation block 115 increases.
It would be beneficial to provide a technique for exchanging data between a PLD and an HLMS in the context of co-simulation which overcomes the difficulties described above.